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The use of behavioural contracts, to specify, regulate and verify systems, is particularly relevant to 
runtime monitoring of distributed systems. System distribution poses major challenges to contract 
monitoring, from monitoring-induced information leaks to computation load balancing, communica- 
tion overheads and fault-tolerance. We present mDPi, a location-aware process calculus, for reason- 
ing about monitoring of distributed systems. We define a family of Labelled Transition Systems for 
this calculus, which allow formal reasoning about different monitoring strategies at different levels of 
abstractions. We also illustrate the expressivity of the calculus by showing how contracts in a simple 
contract language can be synthesised into different mDPi monitors. 

1 Introduction 

As systems continue to grow in size and complexity, the use of behavioural contracts is becoming crucial 
in specifying, regulating and verifying correctness. Various notions of contracts have been used, but most 
prevailing variants enable the regulation of the behaviour of a system, possibly with consequences in case 
of violations. Such contracts can then be used in multiple ways, from system validation and verification, 
to conflict analysis of the contract itself. One important use of contracts is in runtime monitoring: system 
traces are analysed at runtime to ensure that any contract violating behaviour is truncated before it leads 
to any further consequences, possibly applying reparations to recover from anomalous states. 

More and more systems are deployed in a distributed fashion, whether out of our choice or necessity. 
Distribution poses major design challenges for runtime monitoring of contracts, since monitors them- 
selves can be distributed, and trace analysis can be carried out remotely across location. This impacts 
directly various aspects of the system being monitored, from the security of sensitive information, to 
resource management and load balancing, to aspects relating to fault tolerance. Various alternative solu- 
tions have been presented in the literature, from fully orchestrated solutions where monitors are located at 
a central location, to statically distributed monitors where the contract monitor is statically decomposed 
into different components hosted at the location where system traces are generated. 

The primary contribution of this paper is a unified formal framework for studying different monitor- 
ing strategies. We present a location-aware calculus supporting explicit monitoring as a first class entity, 
and internalising behavioural traces at the operational level rather than at a meta-level. We show the 
expressivity of the calculus by using it to model different distributed system monitoring strategies from 
the literature. We also present a novel architecture in which contract monitors migrate across locations to 
keep information monitoring local, while limiting remote monitor instrumentation in certain situations. 
The versatility of the contract-supporting calculus is later illustrated by showing how it can model differ- 
ent instrumentation strategies. In particular, we show how behavioral contracts expressed using regular 
expressions can be automatically translated into monitors of different monitoring strategies. 
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Scheme (Malta). The scholarship is part financed by the European Union European Social Fund. 
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The paper is organised as follows. In section [2j we outline the contract monitoring strategies for 
distributed systems from the literature. We present a monitoring distributed calculus in sections [3] and |4j 
and illustrate its use for monitoring behavioural contracts expressed as regular expressions in section [5] 
We discuss related work and conclude in section[6l 

2 Monitoring Distributed Systems 

Monitoring distributed systems is distinct from monolithic monitoring. These systems are usually char- 
acterised by the absence of a global clock when ordering events across location boundaries. They often 
consist of autonomous, concurrently executing subsystems communicating through message passing, 
each with its local memory, where communication across subsystems is considerably slower than local 
communication. The topology of such systems may sometimes change at runtime through the addition 
of new subsystems or the communication of private channels. Most internet-based and service-oriented 
systems, peer-to-peer systems and Enterprise Service Bus architectures [4] are instances of such systems. 

These characteristics impinge on contract monitoring. For instance, the absence of a global clock 
prohibits precise monitoring for consequentiality contracts across locations ifTTl . Distribution impacts on 
information locality; subsystem events may contain confidential information which must not be exposed 
globally thereby requiring local monitoring. The possibility of distributing monitors also introduces 
concerns for monitor load balancing and monitor replication for fault tolerance. 

Whether monitored contracts are known at compile time or else become known at runtime also affects 
distributed monitoring. Static contracts, ones which are fully known at compile time, are typically not 
expressive enough for distributed systems with dynamic topologies. Dynamic contracts, ones which 
are partially known at compile time, tend to be more appropriate for such systems. They are found in 
intrusion detection [8], where suspicious user behaviour is learnt at runtime, and in systems involving 
service discovery, where the chosen service may come with a fixed or negotiated contract upon discovery. 

2.1 Classifying Distributed System Monitoring Approaches 

Existing approaches for distributed system monitoring can be broadly classified into two categories: or- 
chestration-based or choreography-based. Orchestration-based approaches relegate monitoring respon- 
sibility to a central monitor overhearing all necessary information whereas choreography -based typically 
distribute monitoring across the subsystems. Orchestration, used traditionally in monolithic systems, is 
relatively the simplest strategy and its centralisation facilitates the handling of dynamic contracts. The 
approach is however susceptible to data exposure when contacts concern private information; it also 
leads to considerable communication overhead across locations, and poses a security risk by exposing 
the monitor as a central point of attack. By contrast, choreography-based approaches push verification 
locally, potentially minimising data exposure and communication overhead. Communication between 
localised monitors is typically substantially less than that induced by the remote monitoring of a central 
monitor. Choreography is however more complex to instrument, as contracts need to be decomposed 
into coordinating local monitors, is more intrusive, burdening monitored subsystems with additional lo- 
cal computation, and is applicable only when the subsystems allow local instrumentation of monitoring 
code. Choreographed monitors are also instrumented upfront, which may lead to redundant local instru- 
mentation in the case of consequential contracts; if monitoring at location k is dependent on verification 
at location /, and the check at / is never satisfied, upfront monitor instrumentation at k is never needed. 
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Static orchestration verifying pre-determined contracts is a common approach, e.g., O, where web- 
service compositions are monitored in an orchestrated fashion. By contrast, Q uses orchestration to 
monitor for dynamic properties: web services are centrally monitored against BPMN workflow specifi- 
cations, facilitating the verification of contracts (representing system properties) discovered at runtime 
on-the-fly. Extensive work has also been done in static choreography monitoring fT3l [71 [101 [12j [14ll . 
where communication overhead is mitigated by breaking up contracts into parts which can be monitored 
independently and locally, synchronising between the monitors only when necessary. However, to the 
best of our knowledge, these approaches cannot fully handle dynamic contracts with runtime contract 
decomposition and distribution, nor do they tackle monitor-induced data exposure. 

An alternative approach is that of using migrating monitors, which adequately supports dynamic 
contracts whilst still avoiding orchestration; in particular, it limits instrumentation of distributed monitors 
in cases were monitoring is dependent on computation. Using this approach, monitors reside where the 
immediate confidential traces reside, and migrate to other subsystems, possibly discovered at runtime, 
when information from elsewhere is required i.e., on a by -need basis. This enhanced expressivity also 
permits support for dynamic topologies and contracts learnt at runtime. 
Example 2.1. Consider the hospital system contract: 

A nurse will have access to a patient's records after requesting them, as long as his or her 
request is approved by a doctor assigned to the patient. 
We assume that ( i) the nurse requests ( and eventually accesses ) the patient 's data from a handheld device, 
( ii) the information about which doctors have been assigned to which patients resides at the central site, 
and ( Hi) the patient's information is stored on the doctors' private clinic systems, where doctors can also 
allow nurses permission to access patients ' data. 

A migrating monitor starts on the nurse's system; upon receiving a patient-information request, 
it migrates to the hospital system, decomposes, and spreads to the systems of the patient's assigned 
doctors to check for permissions allowing the nurse access to the records. Finally, if the permission 
is given, the decomposed monitors migrate back to the nurse's device to check that the records are 
available. As with choreographed monitoring, and in contrast to orchestration, migrating monitors can 
ensure that monitoring is performed locally. The main difference is that instrumentation of monitors 
can be performed at runtime. For instance, when monitoring the hospital contract clause, no monitor is 
installed on a doctor's system unless a nurse has made a request for information about a patient assigned 
to that doctor, which is less intrusive. 

The added expressivity of migrating monitors requires a trust management infrastructure to ensure 
safe deployment of received monitors. Various solutions can be applied towards this end, from monitors 
signed by a trusted entity showing that they are the result of an approved contract negotiation procedure, 
to proof-carrying monitors which come with a proof guaranteeing what resources they access. This issue 
will not be discussed further here, but is crucial for the practicality of migrating monitors. 

There are a number of issues relating to these different monitoring approaches that are unresolved. 
For instance, it is somewhat unclear, at least from a formal perspective, what added benefits migration 
brings to distributed monitoring. There are also issues relating to the monitoring of consequential proper- 
ties across locations, which cannot be both sound and complete: in Example |2.1| by the time the monitor 
migrates to the doctor's system, the doctor may have already approved the nurse's request. Distribution 
precludes precise analysis of the relative timing of the traces, and one has the option of taking a worst or 
best case scenario, avoiding false positives or false negatives respectively. This problem is also prevalent 
in both orchestrated and choreographed approaches. We therefore require a common formal framework 
where all three approaches can be expressed. This would, in turn, permit rigorous analysis and evaluation 
with respect to these issues. 
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3 A Distributed Monitoring Language 

We present mDPi, an adaptation of the distributed ^--calculus in [9], where processes are partitioned 
across a fiat organisation of locations; their behaviour is amenable to monitoring through traces, admin- 
istered at a local level. The syntax, presented in Figure [T] assumes denumerable sets of channel names 
c,d e Chans, location names l,k,he Locs, indices n,m,o e Idx and variables x, y e Vars; identifiers u,v 
range over Idents = Chans U Locs U Idx U Vars, with identifier list vi, . . . , v„ denoted as v. 

I 1 
S,R eSvs ::= jfc[P] | S\\R | newc.S 

P,Q€Proc ::= stop | ulv.P | ulx.P | newc.P | if u = v thenP else Q \ P\\Q \ *P \ {M} (l ' n) \ T 

T € Trc ::= \(c,d,n) 

M,N €Mon ::= stop \ u\v.M \ulx.M \ newc.M | if u-v then M else ./V | M\\N \ *M 

| q(c,x).M\ sync(w).M| getl(x,y).M| setl(w,v).M| go u. M | ok | fail 

i I 

Figure 1 : mDPi Syntax 

Systems, S,R, are made up of located processes k^PJ (the tag k denotes the current location hosting 
P ) which can be composed in parallel and subject to scoping of channel names. 

Located entities are partitioned into three syntactic categories: Processes, Proc, comprise the stan- 
dard communication constructs for output, clJ.P, and input, c?x.P (variables x. are bound in the con- 
tinuation P), together with the name-matching conditional, replication, parallel composition and name 
restriction; Traces, are made up of individual trace entities, t(c, d,n) € Trc recording communication of 
values d on channel c at timestamp n - they are meant to be ordered as a complete log recording past 
computation at a particular location; Monitors, Mon, are similar in structure to processes, and are delim- 
ited at the process level by enclosing brackets {M}^ n \ where (k,n) denotes the monitoring context i.e., 
the location and log position of the trace being monitored. In addition, they can: 

• query traces for records of communication on channel c, <\{c,x). M, where the index and location 
of the trace monitored is inferred from the enclosing monitoring context, (k,n). 

• get the information relating to the current monitoring context, qe\\(x,y).M (x,y bound in M), and 
set the monitoring context to specific values k and n, set\(k,n).M, or else update to the current 
timestamp of a location k, sync(k).M, 

• migrate to location k, go k. M, and 

• report success, ok, or failure, fail. 



Shorthand: We often elide trailing stop processes. We thus represent asynchronous outputs such as 
clv.stop as c!v and branches such as if u=v then P else stop as if u=v then P. We also denote k{[M]} < - , ' n) 
as syntactic sugaring for fc|[{Af}^J. 

Our calculus describes distributed, event-based, asynchronous monitoring. Monitoring is asyn- 
chronous because it happens in two phases, whereby the operational mechanism for tracing is detached 
from the operational mechanism for querying the trace. This two-set setup closely reflects the limits im- 
posed by a distributed setting and is more flexible with respect to the various monitoring mechanisms we 
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want to capture. Monitoring is event-based because we chose only to focus on recording and analysing 
discrete events such as communication. 

For simplicity, our calculus only records effected output process events in traces (which dually imply 
effected inputs); we can however extend traces to record other effects of computation in straightforward 
fashion. In order to extract realistic temporal ordering of traces across locations, the calculus provides 
two mechanisms for monitor re-alignment: the coarser (and real-time) sync operation is used to start 
monitoring from a particular instant in time; the more explicit context update setl enables hard-coded 
control of relative timing at the level of monitors. For instance, together with getl, it enables decomposed 
monitoring to hand over tracing at a specific index in a local trace. This mechanism gives more control 
and can improve distributed monitoring precision, but may also lead to unsound monitoring. 

Tracing: Whenever communication occurs (possibly across two locations) on some channel c with 
values v, a trace entity of the form t(c,v,n) is produced at the location where the output resides. The 
output location, which keeps a local counter, assigns the timestamp n to this trace entity and increments 
its counter to n + 1. Local timestamps induce a partial-order amongst all trace entities across the system. 
In particular, we obtain a finite (totally ordered) chain of traces per location. 

Example 3.1 (Distributed Tracing). Consider the distributed system of outputs: 

f[ci!vi] II Hc 2 \v2l II klc 3 \v 3 J 

Assuming that locations I and k have the respective timestamp counters n and m, once all outputs are 
consumed we can obtain either of the following possible sets of trace entities (for simplicity, we assume 
that vi + v%): 

Ht(c u vi,n)J, llt(c 2 ,v 2 ,n+in, klt(c 5 ,v 3 ,m)J (1) 
f[f(ci,v lt n + i;i, Ht(c 2 ,v 2 ,n)J, W(c 3 ,v 3 ,m)l (2) 

The timestamps of trace-set (|7J record the fact that the output on c\ was consumed before that on c% 
whereas those of trace-set (|2]) record the opposite. However, in both of these trace-sets, the timestamp 
assigned to the trace-entity relating to c 3 , recorded at location k, does not indicate the order it was 
consumed, relative to the outputs on c\ and c 2 , which occurred at location I. 

Concurrent Monitoring: In our model, traces may be queried by multiple concurrent entities, which 
allows for better separation of concerns when monitors are instrumented. Trace querying is performed 
exclusively by monitors, l{[M^ k '"\ parameterised by the monitoring context (k,n); indicating that moni- 
tor M is interested in analysing the n th trace record at location k. 

Example 3.2 (Parallel Monitoring). Consider the trace-set (Q from Example \3.1\ A (local) monitor 
determining whether, from timestamp n onwards, a value v 2 was communicated on the first output on 
channel c 2 at location I, can be expressed as: 

l{[q(c 2 ,x).ifx = v 2 then ok else fail]} m 

The counter n of this monitor indicates that it starts analysing the trace-set Qfrom the trace entity 
l^t(ci,V[,n)J and continues moving up the chain of trace entities until the first trace entity describing 
outputs on channel c 2 is encountered. Since l\t(c\,v\,n}\ states that the event occurred on another 
channel, namely c\, the monitor skips the irrelevant trace entity and its index is incremented to n+\ i.e., 
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l{[q(c2,x).if X = V2 then ok else fait]} < ~ 1,n+l \ The monitor analyses the trace entity with the incremented 
timestamp n + \ i.e., l\X(c2,V2,n + \)\ which happens to match the required event on channel en the 
monitor thus substitutes v>2, obtained from the trace entity l\\(c-i,V2,n + \)\ for x and proceeds with the 
monitor processing, which should eventually yield ok. Traces can be concurrently queried by multiple 
monitors. For instance, consider another monitor running in parallel with the previous one of the form: 

l{[q(c u x).q(c 2 ,y).ifx = y then ok else fait]f' n) 

which checks that equal values are communicated on channels C[ and c%. Thus it is important that trace 
entities, such as l\t(c2, v 2 ,n + \)J, are persistent and not consumed once analysed, as in the case of 
outputs in a message passing setting. 

Distributed Monitoring: Distribution adds another dimension of complexity to monitor instrumenta- 
tion, in terms of how to partition monitors across locations and how this partitioning evolves as compu- 
tation progresses. In our calculus, remote querying can be syntactically expressed as &{[q(c,x).M]} ( ''") for 
some c and n, where k + I. We can also describe the different classifications of distributed monitoring 
outlined earlier in Section [2 
Example 3.3. Consider a distributed system 

Sys = llalx.c 2 \x] || newd.(kldlx.c 2 \x] || /[ci \v.d\v.c 2 ^x.stopJ ) 

where c\lx.C2\x and c\\v.d\v.C2^x.stop are located at I whereas d!x.C2\x is located at k. Moreover, 
process dlx.C2\x shares a scoped channel d with c\ \v.d\v.c2lx.st0p. For some timestamps n and m, Sys 
non-deterministically produces either of the traces Q or Q below; the non-determinism is caused by 
the competition for the output on channel C2 by respective inputs at I and k: 

newd.( llt(c u v,n)l, llt(d,v,n + l)J, llt(c 2 ,v,n + 2)J) (3) 
newd.(llt(c u v,n)J, llt(d,v,n + klt(c 2 , v,m)J ) (4) 

The preservation of the property 'Whenever a value e is communicated on the first output on c\ at 
location I, then this value is not output on a subsequent output on channel C2 at k' in general cannot be 
adequately determined statically, due to the non-deterministic nature of the computation, as exhibited by 
the possible traces Q and (Q. However, the property can be monitored at runtime in a number of ways: 

M orch a h{[q( CfX ) m jf x = e then sync(k). q(c,y). ifx-y then fa/7]} (/n) 

M chor a newd > ( i{r q ( Ct x y \f x = e tnen d'\x\\ (l,i) \\ k{[d'lx. sync(k). q(c,y). ifx = y then fail]} (k ' m) ) 
M™'« — l{[q(c,x). ifx = e then go k. sync(k).q(c,y).if x - y then failt m 

M orch monitors for this property in orchestrated fashion, querying traces at both I and kfrom a remote 
central location h; this monitor is well-aligned with location I to start with, but has to explicitly re-align 
with location k once monitoring shifts to that location. M chor is an instance of a choreographed monitor 
setup, instrumenting local monitors at each location where trace querying needs to be performed, namely 
I and k. These local monitors synchonise between them using remote communication on the scoped 
channel d' . Note that the monitor at k updates its context upon channel synchronisation on d' to ensure 
a temporal ordering on analysed trace records; without synchronisation, the monitor would potentially 
be reading past parts of the trace which may lead to unsound sequentiality conclusions. Finally, M' mg 
is a case of a migrating monitor, that starts monitoring at location I but then migrates to location k if it 
needs to continue monitoring there, re-aligning its index to that of the destination location. 
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All three distributed monitors in Example 3.3 are sound wrt. the property stated, in the sense that they 
never falsely flag a violation. They are nevertheless incomplete, and may miss out on detecting property 
violations. For instance, M orch may realign with location k after the trace kftl(c2,v,m)J is generated by 
k, which sets the monitor timestamp index to (k,m+ 1). This forces the monitoring to start querying the 
trace at k from index m + 1 and will therefore skip the relevant trace item k§l(c2,v,m)J. This aspect is 
however not a limitation of our encoding, but rather an inherent char acteristic of distributed computing 
as discussed earlier in Section [2] 



4 Monitoring Semantics 

We define the semantics of mDPi in terms of a number of related Labelled Transition Systems (LTSs), 
which are then used to compare systems through the standard notion of weak-bisimulation equivalence, 
denoted here as «. This framework allows us to state and prove properties from a behavioural perspective 
about our monitored systems. For instance, we could express the fact that, ignoring monitoring location, 



M orch and M chor from Example 3.3 monitor for the same properties wrt. Sys, using the statement: 



Sys || M orch * Sys || M chor (5) 

Using an LTS that does not express observable monitor actions, the property that a monitor, say M orch , 
does not affect the observable behaviour of the system Sys could be stated as: 

Sys a Sys || M orch (6) 

Using different LTSs, the same system could be assigned more restricted behaviour. For instance, this is 



useful to ensure that the monitor M mig of Example 3.3 does not perform remote querying at any stage 



during its computation by establishing the comparison: 

Sys || M mig ~ ((Sys || M mig ) without remote monitoring) (7) 

where the lefthand system is subject to an LTS allowing remote querying whereas the righthand monitor 
is subject to an LTS that prohibits it. Intuitively, if the behaviour is preserved when certain internal moves 
are prohibited, this means that these moves are not used (in any useful way) by the monitor. 



4.1 Deriving LTSs Modularly 

Closer inspection of the comparisons ([5]>, (|6]> and ^ reveals that the different LTSs required are still 
expected to have substantial common structure; typically they would differ with respect to either the 
information carried by actions and/or the type of actions permitted. For instance, in ([5]) we would want 
actions that restrict information relating to the location of where monitoring is carried out, as this ad- 
ditional information would distinguish between the two monitors. On the other hand, for ([7]) we would 
want to prohibit actions relating to remote monitoring. 

We therefore construct these related LTSs in modular fashion through the use of a preLTS, i.e., an 
LTS whose transitions relate more systems, and whose action labels carry more information than actually 
needed. The excess transitions and label information are then pruned out as needed by a. filter function 
from actions in the preLTS to actions in the LTS required. 
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4.2 A preLTS for mDPi 

Our preLTS is defined over systems subject to a local logical clock at every location used by the system, 
which are used to generate ordered trace-entities and to re-align monitors. These clocks are modelled as 
monotonically increasing counters and expressed as a partial function 8 € A :: Locs — 1 N, where 6(1) de- 
notes the next timestamp to be assigned for a trace entity generated at /. Moreover, the counter increment 
is defined using standard function overriding, inc(8,k) = 8[k \-> (8{k) + 1)]. 



OutP : InP ; 

8 > klc\d.PJ """•") inc(<U) > kWl || *[t(c, J,d(Jfc))] 8 > llclx.P] °' > 8 > HP{ d /x}i 

OutT : InT 



8 > kH(c,d,n)J C!rf<?: " : " > ) 8 > jfc[t(c, d,n)J 8 > l{[q(c,x).M]f' n) > 8 > l{[M{d/x}]f' n+l) 



OutM InM : 

8 > k{[c \d.AQ m C[d< "' ± '" ) » ^ > 5 > Z{[c?x.M]} (t ' !) 5 > /{[M{^}]} ( *' n) 

(&)c!<fv 

0pEN [ * * c '" 6 J] Res j » < «W] 

5>newft.5 > 8'>S' 8>newb.S — > 8' > newb.S' 

(b)c\dy cldy 

8>S -4 6'>S' 8>R — -> 8>R' 

ComI [b n fn(R) = 0] 

8>S\\R 8' > new5.(S' \\R!) 

8 > 5 ^''^"S 8>S 8> km m 6 > kW'H il > n+1) 
Skip [ci # C2 ] 

<5 > 5 || ifc{[Af]} ftn) <f: ' , "'" > ) 5 > S || fc{[M]p +1) 
SetI Sync 



<5 > £{[setl(/j, m).M]} (W -^-> 8 > £{[M]} (/vn) 5 > k{[sync(l).M]} {h ' n) 8 > £{[M]p (/)) 

GetI Go 



<5 > k{[ge\\(x,y).M]} il ' n) 8 > JfeffM^^y}]}^ 8 > £{[go f. M]} (?! ' n) 5 > Z{[M]} (M) 



Figure 2: mDPi preLTS main rules 

A Configuration C,D € Conf :: A x Sys is thus a system subject to a set of localised counters. The 
preLTS is a ternary relation — >:: Conf x pAct x Conf, denoted using the suggestive notation C — > D, 
where € pAct is a preLTS action label of the form, r r , an internal action, (b)c\d y , an output action, or 
c?J r , an input action. In case of the output action, b denotes the (possibly empty) set of channel names 
exported during an eventual interaction. These actions are standard [9], but are decorated with additional 
information y which can be of the following three formats: 
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(p : l,k)- This states that it is a process (p) action, involving locations / and k. 

(m : l,k)- This states that it is a monitor (m) action, involving locations / and k. 

(t :l,k: n)- This states that it is a trace (t) action at timestamp n, involving locations / and k, . 

The main rules defining the relation C A D are outlined in Figure]^ The rule for process input, InP, 
is standard, except for the additional label tag (p : k, I) encoding the fact that the input is a process input, 
it resides at location /, and is reading from some location k (when communication is local, then / = k). 
A central rule to our monitoring semantics is OutP. Apart from the additional label decoration, it differs 
from standard output rules in two respects: first it generates a trace entity, k§t(c,d,6(k))J, recording the 
channel name, c, the values communicated, d, timestamped by 8{k), and second, it increments the clock 
at k once the trace entity is generated, necessary for generating a total order of trace-entities at k. Monitor 
communication, defined by rules OutM and InM, is similar albeit simpler since neither trace entities are 
generated, nor is the local counter updated^ 

Rule OutT models trace actions as output labels with tags (t :k,l : n), where the timestamp of the 
trace, n, is recorded in the tag as well. Crucially, the trace entity is not consumed by the action (thereby 
acting as a broadcast), and its persistence allows for multiple monitors to query it. This action can be 
matched by a query action, InT, expressed as an input action with a matching tag {t : k,l : n) where 
the source location of the trace entity, k, and time stamp n must match the current monitoring context 
(k,n). Since the action describes the fact that a trace entity has been matched by the monitor query, the 
timestamp index of the monitoring context is incremented, (k,n + 1) to progress to the next entitity in the 
local trace log. 

Scope extrusion of channel names may occur both directly, through process or monitor communica- 
tion, or else indirectly through trace querying; these are both handled by the standard scoping rules Open 
and Res. All three forms of communication i.e., process, monitor and trace, are also handled uniformly, 
this time by the communication rule ComI (we here elide its symmetric rule). Communication yields a 
silent action r y that is decorated with the corresponding tagging information from the constituent input 
and output actions of the premises. This tagged information must match for both input and output actions 
and, in the case of the trace tags, (t :k,l: n), this also implies a matching of the timestamp n. When, for 
a particular timestamp, querying does not match the channel of the trace entity at that timestamp, rule 
Skip allows the monitor to increase its timestamp index and thus querying to move up the trace-chain at 
that location. Finally, Sync allows monitors to realign with a trace at a particular location, GetI and SetI 
allow for explicit manipulations of the monitoring context whereas Go describes monitor migration. 



4.3 Filter Functions 

Although necessary to encode extended information of system execution, the preLTS presented is too dis- 
criminating. For instance, the internal action r y is now compartementalised into distinct silent actions, 
each identified by the tag information y, which complicates their use for weak actions when verifying 
bisimilar configurations. Similarly, external actions differentiating between a process or a monitor carry- 
ing out that action may also be deemed to discriminating. Finally, we may also want to disallow certain 
actions such as remote trace querying. 



We obtain LTSs with the necessary level of discriminating actions using (i) the preLTS of Section 4.2 



together with (i) a filter function, Q. This function maps actions in the preLTS, p € pAct, to actions in 



Note that rule OutM refers to an indeterminate location h, to match a reader in any such location. 
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the required LTS, a e Act, through the rule: 

Fltr [Q(yu) = a] 

C\ — >n C2 

Notation: Note that filter function applications are essentially abstractions of the preLTS. LTSs ob- 
tained in this manner can effectively be indexed by their respective filter function, Q., and for clarity we 
denote a configuration C subject to a behaviour obtained from the preLTS and a filter function Q. as Cn- 
We also denote transitions obtained in this form as C\ — >n C 2 . 
Example 4.1 (Filter Functions). Consider the following filter function definitions: 

£Wg(Ty)_ = T Qp, r (T r ) = T n LTr (T<f -Ij-n)) = T 

Q. NT g(c\dy) = cW QflcCcI^p:/,^) = cW</,*> ^LTr{T(_:lk)) - T 

Q, NT g(cld y ) = eld Q, Prc (c?d (p -i,k)) - c?J <w Q L Tr(cW r ) = c\d_ 

Q-LTricldy) = dd 

Qjvxg removes all tags from decorated actions, which in turn allows for a straightforward definition 

a t jar 

of weak actions, =>, as ( — >)* ifa-r and ( — >) — > ( — >) otherwise. In addition to stripping r action 
tags, the second filter function, Q.p rc , allows only process external actions, filtering out the p component 
in this case. The function is partial as it is undefined for all other preLTS actions. This is useful when we 
do not want to discriminate configurations based on the tracing and monitoring actions. The final filter 
function, Qlti; removes all tags but uses them to prohibit silent tracing actions where the two locations 
in the tag are distinct; this in effect rules out remote trace querying, thereby enforcing localised trace 
monitoring. 

We assume a certain well-formedness criteria on our filter functions, such as that they do not change 
the form of an action (e.g., an output action remains an output action), and that whenever they map 



to silent actions, t, these are not decorated; the filter functions in Example 4.1 satisfy these criteria 



Through this latter requirement we re-obtain the standard silent r-action at the LTS level. 



4.4 Behavioural Equivalence 



The technical development in sections [472] and [43] allows us to immediately apply weak bisimulation 



as a coinductive proof technique for equivalence between LTSs obtained for our preLTS and well-formed 
filter functions. Two (filtered) LTSs, Cn, and Dq 2 , are bisimilar, denoted as « D& 2 , if they match 
each other's transitions; we use the weak bisimulation variant, «, as this abstracts over internal r-actions 
which yields a more natural extensional equivalence. 



Example 4.2. Using the filter functions defined in Example 4.1 we can formally state and prove equiv- 
alences (Q, (|6]) and ([7|) outlined earlier, for a localised clock-set 8 including locations I and k: 



(6>Sys\\M" rdl )a NTg 
(6 > Sys) nprc 
(6>Sys\\M mi8 )a NTg 



(6>Sys\\M chor )a 



(S>Sys\\M ori;h ) Qprc 
(6>Sys\\M mi Z) [lLT ,. 



(8) 
(9) 
(10) 



Equivalence ([S]) formalises the behaviour expected for ([5]) using an LTS whose actions prohibit distinc- 
tions based on action tags; including monitoring location, i.e., fljvTg- Since in (|6| we wanted to analyse 
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how monitors affect process computation, in its corresponding equivalence Q we use an LTS that tags 
process external actions with location information while prohibiting any actions relating to tracing or 
monitoring. Finally (10) compares M m j g with itself, subject to a restricted semantics where remote mon- 
itoring is prohibited, i.e., Q.ur. 



5 Instrumentation for Distributed Monitoring 

The instrumentation of contracts as distributed monitors is non-trivial and can easily lead to unsound 
contract monitoring. In this section we illustrate how the instrumentation of contracts, expressed using 
a simple regular expression-based temporal logic specifying violation traces, can be safely automated 
according to different monitoring approaches. The syntax of the contract language is: 

E ::= (c,v)@Jfc I E.E \ E* \ E + E 

Basic events have the form (c,v)@k indicating that a communication on channel c with value v occurs 
at location k. We adopt a semantics allowing for multiple matches, rather than opt only for the shortest 
matcrj^jand thus any trace terminating with a communication c\v at location k is considered to be a 
violating trace. The other operators are the standard ones used in regular expressions: E.F corresponds 
to the traces which can be split into two, with the first matching E, and the second matching F; expression 
E* corresponds to traces which can be split into a number (possibly zero) parts, each of which satisfies 
E; and E + F corresponds to the set of traces which match either E or F. 



Notation: £ ee/ E corresponds to the generalised choice over finite /, which is equal to E{>i/ e } + E{'2/e] + 
. . . E{'n/ e } (where / - {h , i 2 . . . , i„}). 

Despite the apparent simplicity of this expository contract language, we can already express interest- 
ing contracts. 



Example 5.1. Consider a simplification of the contract outlined in Example 2.1 ■ "The release of a 
patient's record must be approved by supervising doctors." Stated in terms of what leads to a violation, 
we get: "If a patient's medical record is released regardless of a doctor's disapproval, the contract is 
violated" which can be expressed as the regular expression: 

(req,())@p. ^ (withhold, p)@ d . (send,p)@h 
pePatient deDoctor 

where p, d and h are locations referring to the patient's, the doctor's and the hospital domain, channel 
names req, withhold and send denote actions requesting, withholding and sending medical records, and 
sets Patient and Doctor range over the finite patients and doctors in the system. 

There are different ways in which one may transform a regular expression into an mDPi term. For 
instance, (c\,v\)@k\.{c2,V2)@k2 may be matched by either one monitoring process, M\, or by the split 
monitors, M 2 , below: 

Mi = sync(&i).q(ci,xT).if xT - v]" then (sync(fe)-q(c2,^2). if ^2 = V2 then fail) 

M 2 = (sync(/ci).q(ci,xT).if xi = vf then m!) || (m?.sync(/c2)-q(c2,^)-if X2 = V2 then fail) 



"In any case, when runtime monitoring one may choose to halt the system on the shortest match. 
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Figure 3: Compiling E.F, E + F and E* (respectively) where C,B correspond to comb,bifurc. 



We rind that the second translation, M 2 , lends itself better towards illustrating how monitors can be 
distributed in different ways across locations — for example, in an orchestrated approach, we would 
place all the monitoring processes in a single location, while in a choreographed approach, we would 
distribute the processes as required. A sequential approach such as M\ , may be more approriate in an 
orchestrated approach (since it avoids unnecessary parallelism), but would not be possible to distribute 
to enable choreographed monitoring without further manipulation. 

In this paper, we adopt the maximally parallelised approach, primarily to be able to observe simi- 
larities and distinctions between different compilation approaches. In particular we use this translation 
for a compilation strategy corresponding closely to standard approaches used in hardware compilation 
of regular expressions [6], producing circuits with two additional wires: an input which is signaled upon 
to start matching the regular expression, and an output wire which the circuit uses to signal a match with 
the regular expression. In our case, the wires correspond to channels: basic events (c,v)@k with start 
channel s and match channel / would be translated into an expression which waits for input on channel 
s, then outputs on channel / when an instance of c with v occurs at location k. Our translations also em- 
ploy two standard monitor organisations for funneling two output signals into one and forking channel 
communication onto two separate ones; these are expressed below as the macros comb and bifurc: 

comb(./i, f 2 , f) = ?*./!*) || *(/ 2 ?x./!x) bifurc(s, s u s 2 ) = *j?x.(ji!x II s 2 \x) 

We define three compilation strategies, tpo, <Ac and i//m, corresponding respectively to monitoring using 
orchestration, static choreography and migrating monitoring as discussed in section [2] The compilation 
procedures use three parameters: two control channels (used to notify when the regular expression is to 
start being matched, and to notify when it has matched) and the expression to be compiled. For simplicity, 
all three translations follow a similar pattern shown by the block diagrams in Figure |3j varying only in 
the location placement of the monitors and synchronisation strategy. 

5.1 Orchestration-Based Monitoring Translation 

Orchestration places the monitor at some predefined central location, h. As stated earlier, the lack of 
a global clock prevents it from deducing with certainty the order of events happening across different 
locations. Nevertheless, our translation attempts to mitigate this imprecision for sequence of events 
occurring at the same location using the following mechanism: when a basic event is matched, the 
monitoring context, (k,n), at that moment is recorded using getl and passed as arguments on the match 
signaling channel; this allows subsequent matching to explicitly adjust the monitoring context to these 
values using setl in cases where the location of subsequent events does not change; in cases where 
the location changes, this information is redundant and alignment is carried out using the coarser sync 
command. 

iAo^' /> ((c,v)@k)) = *(s?(xi oc ,x idx )M k = xioc then (seX\(x loc ,x idx ).trg(c,v,f)) else (sync(/c).trg(c,v,/))) 

In either case, a listener triggers a signal with the updated index of the trace on the match channel for 
every event c with data v. Specifically, the macro trg(c,v,/) repeatedly reads from channel c, outputting 
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the monitoring-context information on the matching channel / every time the data traced matches v: 

trg(c,v,/) = *(q(c,x).if x = v then getl(xi oc ,x idx )./!(xi oc ,x idx )) 

The compilation of the regular expression operators matches the compilation schemata of figure [3] 

if/ (s,f,(E.F)) = ne\Nm.(if (s,m,E)\\4/ (m,f,F)) 

xfr' {s, f, E*) = newc, *',/'. comb(s, f,c) || bifurc(c, j',/) || ifi' (s', f, E) 
i// (s,f, (E + F)) = newj 1 ,«,/i,^.(hifiirc( 1 r„ri„S2) II i/ (s u fuE) \\ ^' (s 2 ,f 2 , F) \\ comb(f u f 2 ,f)) 

The combined monitors are located at the predefined central location h, with a dummy initial monitor 
context continuation parameters (h, 1). The monitor induced for a contract E is thus: 

ifro(E)±h{[ne\Ns,f.(s\(.h,l) || *y o (s,f,E) || /?x.fail ) 

5.2 Choreography-Based Monitoring Translation 

Instead of instrumenting the whole monitor at a single central location, a choreography-based approach 
decomposes the monitor into parts, possibly placing them at different locations. Once again, monitors 
are made up of two kinds of components: (i) the event listeners; and (ii) the choreography control logic 
made up of comb and bifurc components. The event listeners are located locally, where the event takes 
place, but are otherwise exactly the same as in the orchestrated approach: 

f c (s, f, ((c,v)@k)) - m' Q {s, f((c,v)@k))]\ iKr) 

On the other hand, the choreography control logic can be placed at any location. For instance one may 
choose to locate them at the node where the next input will be expected, or where the last one occurred. 
For a particular choice of locations / and h, choice E + F is compiled as follows: 

new jj, j 2 ,/i 5 /2.(/{[bifurc(j,Ji,j 2 )]} ftl) II f// c (s lt f lt E) \\ ^' c ((s 2 ,f 2 ),F) \\ h{[comb(fuf 2 ,f)f h ' l) ) 

Finally, we add the necessary start signal (from some start location k) to initiate the monitoring: 

<M£) = news,/. k{[s\(k, 1) || /?x.fail]} (W) || <f c (s, f, E) 

Note that unless all the locations enable the execution of new (monitoring) process at runtime, the 
contracts must be known at compile-time, which is guaranteed in the simple regular expression logic we 
are using. 

5.3 Migrating Monitors Translation 

For the migrating monitors technique, we use a simplified translation where the monitors generated are 
similar to the ones used in orchestration, except that the monitor migrates when required to the relevant 
location (using the go operator). tp' M is defined identical to ifj' Q except for basic events: 

^m(^/'(( c ^) @ ^)) - *(s?(xi oc ,x idx ).gofc. if k = x loc then (setl(xi oc ,x idx ).trg(c,v,/)) else sync(/:).trg(c,v,/)) 
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Note how migration (thus monitor instrumentation) is delayed and happens only once the start signal 
on channel s is received. Initially, the monitor can be chosen to reside anywhere. For a particular location 
choice h, the migrating monitor approach for a contract E would be the following: 



Despite the resemblances resulting from our simplistic translations, migration improves on an orches- 
trated approach by avoiding remote tracing. As in the choreographed approach, one can also choose to 
explicitly run the combining and bifurcation processes at particular locations by adding explicit migra- 
tion instructions. A better approach would be to nest all the monitors within each other to avoid monitors 
migrating or installed before they are actually required. For example, monitoring for an expression of 
the form: {c\,v^@l\c2,V2)@k.{ci,v^)@h would be transformed into a monitor of the form: 

go /. (q(ci,xf).if xT = vT then go k. (q(c 2 ,x^).if X2 = V2 then go h. (q(c3,X3).if xi = V3 then fail))) 

Note that using this approach entails minimal local monitor instrumentation since this happens on a 
by-need basis: the translation avoids installing any monitor at location k unless c\ \v~i happens at /. 

Even within this simplistic formal setting, migrating monitors can be seen to be more versatile than a 
choreographed approach. For instance, if our contract language is extended with variables and a binding 
construct, 3x.E, we could express a more dynamic form of contract such as 3x.(c\,x)@k.(c2,v)@x; 
in such a contract the location of the second event depends on the location communicated in the first 
event and, more importantly, this location is not known at compile time. Because of this last point, this 
contract cannot be handled adequately by traditional choreographed approaches which would need to 
preemptively instrument monitors at every location. However, in a migrating monitor approach, this 
naturally translates to a single runtime migration. 

5.4 The Approaches and Limitations 

We have shown how one can formulate different monitoring strategies of the same contract using mDPi. 
The contract language and its compilation procedure have intentionally been kept simple to avoid their 
complexity from obscuring the underlying monitoring choices. The different approaches mostly differ 
only in the location of the monitors. The migrating monitor approach also allows for straightforward 
setting up of new contracts at runtime, including references to locations not known at compile-time. 
Furthermore, the migrating approach procrastinates from setting up monitors in remote locations until 
necessary. In contrast, on a choreographed approach, monitors are set up at all locations, even though 
some of them may never be triggered. 

Formalising the compilation of regular expression contracts into mDPi also gives us opportunities to 
formally verifying certain properties. For instance, as a generalisation of ([8]> we can state and prove that, 
for arbitrary expression E, different compilation approaches give the same monitoring result. We can 
state this as: 



ifr M (E)±hln&Ns,fXsKh,l) || *' M {s,f,E) || /?x.fail ) ]} 



(h,i) 



6 > Sys || i/f (E))a NTg 



(6>Sys\\i/,c(E))a, 



'•NTg 



(8>Sys\\ME)) a - 



and prove it by giving witness bisimulations defined by induction on the structure of E. One can prove 
similar results on the lines of the equivalences given in section 4.4 
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6 Conclusions 

We have presented a novel process calculus framework in which distributed contract monitoring can 
be formalised and analysed. We have shown it to be expressive enough to encode various distributed 
monitoring strategies. To the best of our knowledge, it is unique in that it traces are first class entities 
rather than meta-constructs. We modularly developed various semantics for this calculus, using transition 
abstraction techniques that enable selective reasoning about aspects such as locality of communication 
and distinctions between monitor and process actions. 

We are currently working on an implementation in Erlang [2], guided by the design decisions made 
for our calculus. This should give us insight into practical issues, such as that of addressing trust is- 
sues when installing monitors and the avoidance of indirect data exposure due to monitoring. We are 
also studying mDPi further, addressing issues such as clock boundaries and real-time operators. As 
the calculus stands, the monitoring component is non-intrusive, in that it reads system events but does 
not otherwise interact with it. To handle reparations and enforcements upon contract violation, and to 
be able to express monitor-oriented programming [5 ] we require potentially intrusive monitoring. We 
believe that our bisimulation approach can also handle reasoning about monitor intrusiveness. 
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